การโหลดทรัพยากรด้วย React Suspense: เชี่ยวชาญรูปแบบการดึงข้อมูลสมัยใหม่

ในโลกของการพัฒนาเว็บที่เปลี่ยนแปลงอย่างรวดเร็ว ประสบการณ์ผู้ใช้ (UX) คือสิ่งสำคัญที่สุด แอปพลิเคชันถูกคาดหวังให้รวดเร็ว ตอบสนองได้ดี และน่าใช้งาน ไม่ว่าสภาพเครือข่ายหรือความสามารถของอุปกรณ์จะเป็นอย่างไร สำหรับนักพัฒนา React นี่มักหมายถึงการจัดการ state ที่ซับซ้อน, loading indicators ที่ยุ่งยาก และการต่อสู้กับการเกิด data fetching waterfalls อยู่เสมอ ขอแนะนำ React Suspense ซึ่งเป็นฟีเจอร์ที่ทรงพลัง แม้จะมักถูกเข้าใจผิด แต่ก็ถูกออกแบบมาเพื่อเปลี่ยนแปลงวิธีที่เราจัดการกับการทำงานแบบ asynchronous โดยเฉพาะการดึงข้อมูล

เดิมทีถูกแนะนำให้ใช้สำหรับการทำ code splitting ด้วย React.lazy() แต่ศักยภาพที่แท้จริงของ Suspense อยู่ที่ความสามารถในการจัดการการโหลดทรัพยากรแบบ asynchronous *ใดๆ* ก็ตาม รวมถึงข้อมูลจาก API คู่มือฉบับสมบูรณ์นี้จะเจาะลึกเกี่ยวกับการใช้ React Suspense สำหรับการโหลดทรัพยากร สำรวจแนวคิดหลัก รูปแบบพื้นฐานของการดึงข้อมูล และข้อควรพิจารณาในทางปฏิบัติสำหรับการสร้างแอปพลิเคชันระดับโลกที่มีประสิทธิภาพและทนทาน

วิวัฒนาการของการดึงข้อมูลใน React: จาก Imperative สู่ Declarative

เป็นเวลาหลายปีที่การดึงข้อมูลในคอมโพเนนต์ของ React อาศัยรูปแบบทั่วไปเป็นหลัก: ใช้ hook useEffect เพื่อเริ่มการเรียก API, จัดการสถานะการโหลดและข้อผิดพลาดด้วย useState, และแสดงผลตามเงื่อนไขของสถานะเหล่านั้น แม้จะใช้งานได้ แต่วิธีนี้มักนำไปสู่ความท้าทายหลายประการ:

• การเพิ่มขึ้นของสถานะการโหลด (Loading State Proliferation): เกือบทุกคอมโพเนนต์ที่ต้องการข้อมูลจำเป็นต้องมี state isLoading, isError, และ data ของตัวเอง ซึ่งนำไปสู่ boilerplate code ที่ซ้ำซ้อน
• Waterfalls และ Race Conditions: คอมโพเนนต์ซ้อนกันที่ดึงข้อมูลมักส่งผลให้เกิดการร้องขอแบบตามลำดับ (waterfalls) โดยคอมโพเนนต์แม่จะดึงข้อมูล จากนั้นจึง render แล้วคอมโพเนนต์ลูกจึงจะเริ่มดึงข้อมูลของตัวเอง وهكذا สิ่งนี้เพิ่มเวลาในการโหลดโดยรวม นอกจากนี้ยังอาจเกิด Race conditions ได้เมื่อมีการร้องขอหลายรายการพร้อมกัน และการตอบกลับมาถึงไม่เป็นไปตามลำดับ
• การจัดการข้อผิดพลาดที่ซับซ้อน: การกระจายข้อความแสดงข้อผิดพลาดและตรรกะการกู้คืนไปยังคอมโพเนนต์จำนวนมากอาจเป็นเรื่องยุ่งยาก ต้องใช้ prop drilling หรือโซลูชันการจัดการ state แบบ global
• ประสบการณ์ผู้ใช้ที่ไม่น่าพอใจ: การมี spinners หลายตัวปรากฏขึ้นและหายไป หรือการเปลี่ยนแปลงเนื้อหาอย่างกะทันหัน (layout shifts) อาจสร้างประสบการณ์ที่น่ารำคาญสำหรับผู้ใช้
• Prop Drilling สำหรับข้อมูลและสถานะ: การส่งต่อข้อมูลที่ดึงมาและสถานะการโหลด/ข้อผิดพลาดที่เกี่ยวข้องลงไปหลายระดับของคอมโพเนนต์กลายเป็นแหล่งความซับซ้อนที่พบบ่อย

พิจารณาสถานการณ์การดึงข้อมูลทั่วไปโดยไม่มี Suspense:

            import React, { useState, useEffect } from 'react';

function UserProfile({ userId }) {
  const [user, setUser] = useState(null);
  const [isLoading, setIsLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    const fetchUser = async () => {
      try {
        setIsLoading(true);
        const response = await fetch(`/api/users/${userId}`);
        if (!response.ok) {
          throw new Error(`HTTP error! status: ${response.status}`);
        }
        const data = await response.json();
        setUser(data);
      } catch (e) {
        setError(e);
      } finally {
        setIsLoading(false);
      }
    };
    fetchUser();
  }, [userId]);

  if (isLoading) {
    return <p>Loading user profile...</p>;
  }

  if (error) {
    return <p style={"color: red;"}>Error: {error.message}</p>;
  }

  if (!user) {
    return <p>No user data available.</p>;
  }

  return (
    <div>
      <h2>User: {user.name}</h2>
      <p>Email: {user.email}</p>
      <!-- More user details -->
    </div>
  );
}

function App() {
  return (
    <div>
      <h1>Welcome to the Application</h1>
      <UserProfile userId={"123"} />
    </div>
  );
}

            

              
                Copy
              
            
          

รูปแบบนี้เป็นที่แพร่หลาย แต่บีบให้คอมโพเนนต์ต้องจัดการสถานะ asynchronous ของตัวเอง ซึ่งมักนำไปสู่ความสัมพันธ์ที่ผูกมัดกันอย่างแน่นหนาระหว่าง UI และตรรกะการดึงข้อมูล Suspense นำเสนอทางเลือกที่เป็น declarative และคล่องตัวกว่า

ทำความเข้าใจ React Suspense ที่เหนือกว่า Code Splitting

นักพัฒนาส่วนใหญ่พบกับ Suspense เป็นครั้งแรกผ่าน React.lazy() สำหรับการทำ code splitting ซึ่งช่วยให้คุณสามารถเลื่อนการโหลดโค้ดของคอมโพเนนต์ออกไปจนกว่าจะจำเป็นต้องใช้ ตัวอย่างเช่น:

            import React, { Suspense, lazy } from 'react';

const LazyComponent = lazy(() => import('./MyHeavyComponent'));

function App() {
  return (
    <Suspense fallback={<div>Loading component...</div>}>
      <LazyComponent />
    </Suspense>
  );
}

            

              
                Copy
              
            
          

ในสถานการณ์นี้ หาก MyHeavyComponent ยังไม่ได้ถูกโหลด ขอบเขตของ <Suspense> จะจับ promise ที่ถูก throw โดย lazy() และแสดง fallback จนกว่าโค้ดของคอมโพเนนต์จะพร้อมใช้งาน ข้อสังเกตที่สำคัญคือ Suspense ทำงานโดยการจับ promise ที่ถูก throw ระหว่างการ render

กลไกนี้ไม่ได้จำกัดอยู่แค่การโหลดโค้ดเท่านั้น ฟังก์ชันใดๆ ที่ถูกเรียกใช้ระหว่างการ render และ throw promise (เช่น เพราะทรัพยากรยังไม่พร้อมใช้งาน) สามารถถูกจับโดย Suspense boundary ที่อยู่สูงขึ้นไปใน component tree ได้ เมื่อ promise ถูก resolve, React จะพยายาม re-render คอมโพเนนตนั้นอีกครั้ง และหากตอนนี้ทรัพยากรพร้อมใช้งานแล้ว fallback จะถูกซ่อนและเนื้อหาจริงจะถูกแสดงขึ้นมา

แนวคิดหลักของ Suspense สำหรับการดึงข้อมูล

เพื่อใช้ประโยชน์จาก Suspense สำหรับการดึงข้อมูล เราต้องเข้าใจหลักการสำคัญบางประการ:

1. การ Throw Promise

แตกต่างจากโค้ด asynchronous แบบดั้งเดิมที่ใช้ async/await เพื่อ resolve promise, Suspense อาศัยฟังก์ชันที่ *throw* promise หากข้อมูลยังไม่พร้อม เมื่อ React พยายาม render คอมโพเนนต์ที่เรียกใช้ฟังก์ชันดังกล่าว และข้อมูลยังคงรอดำเนินการ promise จะถูก throw ออกไป จากนั้น React จะ 'หยุด' การ render คอมโพเนนต์นั้นและลูกๆ ของมันชั่วคราว เพื่อมองหา <Suspense> boundary ที่ใกล้ที่สุด

2. The Suspense Boundary

คอมโพเนนต์ <Suspense> ทำหน้าที่เป็น error boundary สำหรับ promise มันรับ prop ที่ชื่อว่า fallback ซึ่งเป็น UI ที่จะแสดงในขณะที่คอมโพเนนต์ลูก (หรือลูกหลาน) ใดๆ ของมันกำลัง suspending (กล่าวคือ กำลัง throw promise) เมื่อ promise ทั้งหมดที่ถูก throw ภายใน subtree ของมัน resolve แล้ว fallback จะถูกแทนที่ด้วยเนื้อหาจริง

Suspense boundary หนึ่งอันสามารถจัดการการทำงานแบบ asynchronous ได้หลายอย่าง ตัวอย่างเช่น หากคุณมีสองคอมโพเนนต์ภายใน <Suspense> boundary เดียวกัน และแต่ละคอมโพเนนต์ต้องการดึงข้อมูล fallback จะแสดงผลจนกว่าการดึงข้อมูล *ทั้งสอง* จะเสร็จสมบูรณ์ สิ่งนี้ช่วยหลีกเลี่ยงการแสดง UI ที่ไม่สมบูรณ์และมอบประสบการณ์การโหลดที่มีการประสานงานที่ดีขึ้น

3. ตัวจัดการแคช/ทรัพยากร (ความรับผิดชอบของ Userland)

สิ่งสำคัญคือ Suspense เองไม่ได้จัดการเรื่องการดึงข้อมูลหรือการแคช มันเป็นเพียงกลไกการประสานงาน เพื่อให้ Suspense ทำงานกับการดึงข้อมูลได้ คุณต้องมีเลเยอร์ที่:

• เริ่มต้นการดึงข้อมูล
• แคชผลลัพธ์ (ข้อมูลที่ resolve แล้ว หรือ promise ที่กำลังรอ)
• มีเมธอด read() แบบ synchronous ที่จะคืนค่าข้อมูลที่แคชไว้ทันที (ถ้ามี) หรือ throw promise ที่กำลังรออยู่ (ถ้าไม่มี)

'ตัวจัดการทรัพยากร' นี้มักจะถูกสร้างขึ้นโดยใช้แคชแบบง่ายๆ (เช่น Map หรือ object) เพื่อจัดเก็บสถานะของแต่ละทรัพยากร (pending, resolved, หรือ errored) แม้ว่าคุณจะสามารถสร้างสิ่งนี้ด้วยตนเองเพื่อการสาธิตได้ แต่ในแอปพลิเคชันจริง คุณควรใช้ไลบรารีการดึงข้อมูลที่แข็งแกร่งซึ่งทำงานร่วมกับ Suspense

4. Concurrent Mode (การปรับปรุงใน React 18)

แม้ว่า Suspense จะสามารถใช้ได้ใน React เวอร์ชันเก่า แต่พลังเต็มรูปแบบของมันจะถูกปลดปล่อยออกมาด้วย Concurrent React (เปิดใช้งานโดยปริยายใน React 18 ด้วย createRoot) Concurrent Mode ช่วยให้ React สามารถขัดจังหวะ หยุดชั่วคราว และกลับมาทำงาน render ต่อได้ ซึ่งหมายความว่า:

• การอัปเดต UI ที่ไม่บล็อก: เมื่อ Suspense แสดง fallback, React สามารถทำการ render ส่วนอื่นๆ ของ UI ที่ไม่ได้ถูก suspend ต่อไปได้ หรือแม้กระทั่งเตรียม UI ใหม่ในเบื้องหลังโดยไม่บล็อก main thread
• Transitions: API ใหม่อย่าง useTransition ช่วยให้คุณสามารถทำเครื่องหมายการอัปเดตบางอย่างว่าเป็น 'transitions' ซึ่ง React สามารถขัดจังหวะและทำให้มีความเร่งด่วนน้อยลงได้ ทำให้การเปลี่ยนแปลง UI ระหว่างการดึงข้อมูลเป็นไปอย่างราบรื่นขึ้น

รูปแบบการดึงข้อมูลด้วย Suspense

มาสำรวจวิวัฒนาการของรูปแบบการดึงข้อมูลด้วยการมาถึงของ Suspense กัน

รูปแบบที่ 1: Fetch-Then-Render (แบบดั้งเดิมที่ห่อด้วย Suspense)

นี่เป็นแนวทางคลาสสิกที่ข้อมูลจะถูกดึงก่อน แล้วจึง render คอมโพเนนต์ แม้ว่าจะไม่ได้ใช้ประโยชน์จากกลไก 'throw promise' โดยตรงสำหรับข้อมูล แต่คุณสามารถห่อคอมโพเนนต์ที่ *ในที่สุด* จะ render ข้อมูลใน Suspense boundary เพื่อให้มี fallback ได้ นี่เป็นเรื่องเกี่ยวกับการใช้ Suspense เป็นตัวจัดการ UI การโหลดทั่วไปสำหรับคอมโพเนนต์ที่พร้อมใช้งานในที่สุด แม้ว่าการดึงข้อมูลภายในของมันจะยังคงเป็นแบบ useEffect แบบดั้งเดิมก็ตาม

            import React, { Suspense, useState, useEffect } from 'react';

function UserDetails({ userId }) {
  const [user, setUser] = useState(null);
  const [isLoading, setIsLoading] = useState(true);

  useEffect(() => {
    const fetchUserData = async () => {
      setIsLoading(true);
      const res = await fetch(`/api/users/${userId}`);
      const data = await res.json();
      setUser(data);
      setIsLoading(false);
    };
    fetchUserData();
  }, [userId]);

  if (isLoading) {
    return <p>Loading user details...</p>;
  }

  return (
    <div>
      <h3>User: {user.name}</h3>
      <p>Email: {user.email}</p>
    </div>
  );
}

function App() {
  return (
    <div>
      <h1>Fetch-Then-Render Example</h1>
      <Suspense fallback={<div>Overall page loading...</div>}>
        <UserDetails userId={"1"} />
      </Suspense>
    </div>
  );
}

            

              
                Copy
              
            
          

ข้อดี: เข้าใจง่าย, เข้ากันได้กับโค้ดเก่า สามารถใช้เป็นวิธีที่รวดเร็วในการเพิ่มสถานะการโหลดแบบ global

ข้อเสีย: ไม่ได้กำจัด boilerplate ภายใน UserDetails ยังคงเสี่ยงต่อการเกิด waterfalls หากคอมโพเนนต์ดึงข้อมูลตามลำดับ ไม่ได้ใช้ประโยชน์จากกลไก 'throw-and-catch' ของ Suspense สำหรับข้อมูลอย่างแท้จริง

รูปแบบที่ 2: Render-Then-Fetch (การดึงข้อมูลภายใน Render, ไม่เหมาะสำหรับ Production)

รูปแบบนี้มีไว้เพื่อแสดงให้เห็นถึงสิ่งที่ ไม่ควรทำ กับ Suspense โดยตรงเป็นหลัก เนื่องจากอาจนำไปสู่ infinite loops หรือปัญหาด้านประสิทธิภาพหากไม่ได้รับการจัดการอย่างพิถีพิถัน มันเกี่ยวข้องกับการพยายามดึงข้อมูลหรือเรียกฟังก์ชันที่ suspend โดยตรงภายใน render phase ของคอมโพเนนต์ *โดยไม่มี* กลไกการแคชที่เหมาะสม

            // DO NOT USE THIS IN PRODUCTION WITHOUT A PROPER CACHING LAYER
// This is purely for illustration of how a direct 'throw' might work conceptually.

let fetchedData = null;
let dataPromise = null;

function fetchDataSynchronously(url) {
  if (fetchedData) {
    return fetchedData;
  }

  if (!dataPromise) {
    dataPromise = fetch(url)
      .then(res => res.json())
      .then(data => { fetchedData = data; dataPromise = null; return data; })
      .catch(err => { dataPromise = null; throw err; });
  }
  throw dataPromise; // This is where Suspense kicks in
}

function UserDetailsBadExample({ userId }) {
  const user = fetchDataSynchronously(`/api/users/${userId}`);
  return (
    <div>
      <h3>User: {user.name}</h3>
      <p>Email: {user.email}</p>
    </div>
  );
}

function App() {
  return (
    <div>
      <h1>Render-Then-Fetch (Illustrative, NOT Recommended Directly)</h1>
      <Suspense fallback={<div>Loading user...</div>}>
        <UserDetailsBadExample userId={"2"} />
      </Suspense>
    </div>
  );
}

            

              
                Copy
              
            
          

ข้อดี: แสดงให้เห็นว่าคอมโพเนนต์สามารถ 'ขอ' ข้อมูลโดยตรงและ suspend หากยังไม่พร้อมได้อย่างไร

ข้อเสีย: มีปัญหาอย่างมากสำหรับ production ระบบ fetchedData และ dataPromise แบบ global และทำด้วยตนเองนี้เรียบง่ายเกินไป ไม่สามารถจัดการกับการร้องขอหลายรายการ, การ invalidation หรือสถานะข้อผิดพลาดได้อย่างมีประสิทธิภาพ เป็นเพียงภาพประกอบเบื้องต้นของแนวคิด 'throw-a-promise' ไม่ใช่รูปแบบที่ควรนำไปใช้

รูปแบบที่ 3: Fetch-As-You-Render (รูปแบบในอุดมคติของ Suspense)

นี่คือการเปลี่ยนแปลงกระบวนทัศน์ที่ Suspense ช่วยให้เกิดขึ้นได้จริงสำหรับการดึงข้อมูล แทนที่จะรอให้คอมโพเนนต์ render ก่อนที่จะเริ่มดึงข้อมูล หรือดึงข้อมูลทั้งหมดล่วงหน้า Fetch-As-You-Render หมายถึงคุณเริ่มดึงข้อมูล *โดยเร็วที่สุด* ซึ่งมักจะ *ก่อน* หรือ *พร้อมๆ กับ* กระบวนการ render จากนั้นคอมโพเนนต์จะ 'อ่าน' ข้อมูลจากแคช และหากข้อมูลยังไม่พร้อม คอมโพเนนต์ก็จะ suspend แนวคิดหลักคือการแยกตรรกะการดึงข้อมูลออกจากตรรกะการ render ของคอมโพเนนต์

เพื่อที่จะใช้งาน Fetch-As-You-Render คุณต้องมีกลไกที่สามารถ:

1. เริ่มต้นการดึงข้อมูลนอกฟังก์ชัน render ของคอมโพเนนต์ (เช่น เมื่อเข้าสู่ route หรือเมื่อคลิกปุ่ม)
2. จัดเก็บ promise หรือข้อมูลที่ resolve แล้วในแคช
3. มีวิธีให้คอมโพเนนต์ 'อ่าน' จากแคชนี้ได้ หากข้อมูลยังไม่พร้อมใช้งาน ฟังก์ชัน read จะ throw promise ที่กำลังรอดำเนินการ

รูปแบบนี้ช่วยแก้ปัญหา waterfall ได้ หากคอมโพเนนต์สองตัวที่แตกต่างกันต้องการข้อมูล การร้องขอของพวกเขาสามารถเริ่มต้นได้พร้อมกัน และ UI จะปรากฏขึ้นก็ต่อเมื่อ *ทั้งสอง* รายการพร้อมแล้ว โดยมีการประสานงานจาก Suspense boundary เพียงอันเดียว

การสร้างด้วยตนเอง (เพื่อความเข้าใจ)

เพื่อให้เข้าใจกลไกเบื้องหลัง เรามาสร้างตัวจัดการทรัพยากรแบบง่ายๆ ด้วยตนเองกัน ในแอปพลิเคชันจริง คุณควรใช้ไลบรารีเฉพาะทาง

            import React, { Suspense } from 'react';

// --- Simple Cache/Resource Manager --- //
const cache = new Map();

function createResource(promise) {
  let status = 'pending';
  let result;
  let suspender = promise.then(
    (r) => {
      status = 'success';
      result = r;
    },
    (e) => {
      status = 'error';
      result = e;
    }
  );

  return {
    read() {
      if (status === 'pending') {
        throw suspender;
      } else if (status === 'error') {
        throw result;
      } else if (status === 'success') {
        return result;
      }
    },
  };
}

function fetchData(key, fetcher) {
  if (!cache.has(key)) {
    cache.set(key, createResource(fetcher()));
  }
  return cache.get(key);
}

// --- Data Fetching Functions --- //
const fetchUserById = (id) => {
  console.log(`Fetching user ${id}...`);
  return new Promise(resolve => setTimeout(() => {
    const users = {
      '1': { id: '1', name: 'Alice Smith', email: 'alice@example.com' },
      '2': { id: '2', name: 'Bob Johnson', email: 'bob@example.com' },
      '3': { id: '3', name: 'Charlie Brown', email: 'charlie@example.com' }
    };
    resolve(users[id]);
  }, 1500));
};

const fetchPostsByUserId = (userId) => {
  console.log(`Fetching posts for user ${userId}...`);
  return new Promise(resolve => setTimeout(() => {
    const posts = {
      '1': [{ id: 'p1', title: 'My First Post' }, { id: 'p2', title: 'Travel Adventures' }],
      '2': [{ id: 'p3', title: 'Coding Insights' }],
      '3': [{ id: 'p4', title: 'Global Trends' }, { id: 'p5', title: 'Local Cuisine' }]
    };
    resolve(posts[userId] || []);
  }, 2000));
};

// --- Components --- //
function UserProfile({ userId }) {
  const userResource = fetchData(`user-${userId}`, () => fetchUserById(userId));
  const user = userResource.read(); // This will suspend if user data is not ready

  return (
    <div>
      <h3>User: {user.name}</h3>
      <p>Email: {user.email}</p>
    </div>
  );
}

function UserPosts({ userId }) {
  const postsResource = fetchData(`posts-${userId}`, () => fetchPostsByUserId(userId));
  const posts = postsResource.read(); // This will suspend if posts data is not ready

  return (
    <div>
      <h4>Posts by {userId}:</h4>
      <ul>
        {posts.map(post => (
          <li key={post.id}>{post.title}</li>
        ))}
        {posts.length === 0 && <li>No posts found.</li>}
      </ul>
    </div>
  );
}

// --- Application --- //
let initialUserResource = null;
let initialPostsResource = null;

function prefetchDataForUser(userId) {
  initialUserResource = fetchData(`user-${userId}`, () => fetchUserById(userId));
  initialPostsResource = fetchData(`posts-${userId}`, () => fetchPostsByUserId(userId));
}

// Pre-fetch some data before the App component even renders
prefetchDataForUser('1');

function App() {
  return (
    <div>
      <h1>Fetch-As-You-Render with Suspense</h1>
      <p>This demonstrates how data fetching can happen in parallel, coordinated by Suspense.</p>

      <Suspense fallback={<div>Loading user profile and posts...</div>}>
        <UserProfile userId={"1"} />
        <UserPosts userId={"1"} />
      </Suspense>

      <h2>Another Section</h2>
      <Suspense fallback={<div>Loading different user...</div>}>
        <UserProfile userId={"2"} />
      </Suspense>
    </div>
  );
}

            

              
                Copy
              
            
          

ในตัวอย่างนี้:

• ฟังก์ชัน createResource และ fetchData สร้างกลไกการแคชพื้นฐาน
• เมื่อ UserProfile หรือ UserPosts เรียกใช้ resource.read() พวกมันจะได้รับข้อมูลทันทีหรือ promise จะถูก throw
• <Suspense> boundary ที่ใกล้ที่สุดจะจับ promise และแสดง fallback ของมัน
• สิ่งสำคัญคือ เราสามารถเรียก prefetchDataForUser('1') *ก่อน* ที่คอมโพเนนต์ App จะ render ซึ่งช่วยให้การดึงข้อมูลเริ่มได้เร็วยิ่งขึ้น

ไลบรารีสำหรับ Fetch-As-You-Render

การสร้างและบำรุงรักษาตัวจัดการทรัพยากรที่แข็งแกร่งด้วยตนเองนั้นซับซ้อน โชคดีที่มีไลบรารีการดึงข้อมูลที่成熟หลายตัวที่ได้นำ Suspense มาใช้หรือกำลังนำมาใช้ โดยมีโซลูชันที่ผ่านการทดสอบมาอย่างดี:

• React Query (TanStack Query): มีเลเยอร์การดึงข้อมูลและการแคชที่ทรงพลังพร้อมการรองรับ Suspense มี hook อย่าง useQuery ที่สามารถ suspend ได้ เหมาะสำหรับ REST APIs อย่างยิ่ง
• SWR (Stale-While-Revalidate): ไลบรารีการดึงข้อมูลที่ได้รับความนิยมและมีน้ำหนักเบาอีกตัวที่รองรับ Suspense อย่างเต็มรูปแบบ เหมาะสำหรับ REST APIs โดยเน้นการให้ข้อมูลอย่างรวดเร็ว (stale) แล้วจึง revalidate ในเบื้องหลัง
• Apollo Client: GraphQL client ที่ครอบคลุมซึ่งมีการผสานรวม Suspense ที่แข็งแกร่งสำหรับ GraphQL queries และ mutations
• Relay: GraphQL client ของ Facebook เอง ซึ่งออกแบบมาตั้งแต่ต้นสำหรับ Suspense และ Concurrent React มันต้องการ GraphQL schema และขั้นตอนการคอมไพล์ที่เฉพาะเจาะจง แต่ให้ประสิทธิภาพและความสอดคล้องของข้อมูลที่ไม่มีใครเทียบได้
• Urql: GraphQL client ที่มีน้ำหนักเบาและปรับแต่งได้สูงพร้อมการรองรับ Suspense

ไลบรารีเหล่านี้ช่วยลดความซับซ้อนของการสร้างและจัดการทรัพยากร, การจัดการแคช, การ revalidation, optimistic updates และการจัดการข้อผิดพลาด ทำให้การใช้งาน Fetch-As-You-Render ง่ายขึ้นมาก

รูปแบบที่ 4: การ Prefetching ด้วยไลบรารีที่รองรับ Suspense

Prefetching เป็นการเพิ่มประสิทธิภาพที่ทรงพลัง โดยที่คุณจะดึงข้อมูลที่ผู้ใช้น่าจะต้องการในอนาคตอันใกล้มาล่วงหน้า ก่อนที่พวกเขาจะร้องขออย่างชัดเจน สิ่งนี้สามารถปรับปรุงประสิทธิภาพที่ผู้ใช้รับรู้ได้อย่างมาก

ด้วยไลบรารีที่รองรับ Suspense การ prefetching จะกลายเป็นเรื่องง่ายดาย คุณสามารถกระตุ้นการดึงข้อมูลจากการโต้ตอบของผู้ใช้ที่ไม่เปลี่ยนแปลง UI ทันที เช่น การวางเมาส์เหนือลิงก์หรือปุ่ม

            import React, { Suspense } from 'react';
import { QueryClient, QueryClientProvider, useQuery } from '@tanstack/react-query';

// Assume these are your API calls
const fetchProductById = async (id) => {
  console.log(`Fetching product ${id}...`);
  return new Promise(resolve => setTimeout(() => {
    const products = {
      'A001': { id: 'A001', name: 'Global Widget X', price: 29.99, description: 'A versatile widget for international use.' },
      'B002': { id: 'B002', name: 'Universal Gadget Y', price: 149.99, description: 'Cutting-edge gadget, loved worldwide.' },
    };
    resolve(products[id]);
  }, 1000));
};

const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      suspense: true, // Enable Suspense for all queries by default
    },
  },
});

function ProductDetails({ productId }) {
  const { data: product } = useQuery({
    queryKey: ['product', productId],
    queryFn: () => fetchProductById(productId),
  });

  return (
    <div style={{\"border\": \"1px solid #ccc\", \"padding\": \"15px\", \"margin\": \"10px 0\"}}>
      <h3>{product.name}</h3>
      <p>Price: ${product.price.toFixed(2)}</p>
      <p>{product.description}</p>
    </div>
  );
}

function ProductList() {
  const handleProductHover = (productId) => {
    // Prefetch data when a user hovers over a product link
    queryClient.prefetchQuery({
      queryKey: ['product', productId],
      queryFn: () => fetchProductById(productId),
    });
    console.log(`Prefetching product ${productId}`);
  };

  return (
    <div>
      <h2>Available Products:</h2>
      <ul>
        <li>
          <a href=\"#\" onMouseEnter={() => handleProductHover('A001')}
             onClick={(e) => { e.preventDefault(); /* Navigate or show details */ }}
          >Global Widget X (A001)</a>
        </li>
        <li>
          <a href=\"#\" onMouseEnter={() => handleProductHover('B002')}
             onClick={(e) => { e.preventDefault(); /* Navigate or show details */ }}
          >Universal Gadget Y (B002)</a>
        </li>
      </ul>
      <p>Hover over a product link to see prefetching in action. Open network tab to observe.</p>
    </div>
  );
}

function App() {
  const [showProductA, setShowProductA] = React.useState(false);
  const [showProductB, setShowProductB] = React.useState(false);

  return (
    <QueryClientProvider client={queryClient}>
      <h1>Prefetching with React Suspense (React Query)</h1>
      <ProductList />

      <button onClick={() => setShowProductA(true)}>Show Global Widget X</button>
      <button onClick={() => setShowProductB(true)}>Show Universal Gadget Y</button>

      {showProductA && (
        <Suspense fallback={<p>Loading Global Widget X...</p>}>
          <ProductDetails productId=\"A001\" />
        </Suspense>
      )}
      {showProductB && (
        <Suspense fallback={<p>Loading Universal Gadget Y...</p>}>
          <ProductDetails productId=\"B002\" />
        </Suspense>
      )}
    </QueryClientProvider>
  );
}

            

              
                Copy
              
            
          

ในตัวอย่างนี้ การวางเมาส์เหนือลิงก์ผลิตภัณฑ์จะกระตุ้น `queryClient.prefetchQuery` ซึ่งเริ่มการดึงข้อมูลในเบื้องหลัง หากผู้ใช้คลิกปุ่มเพื่อแสดงรายละเอียดผลิตภัณฑ์ และข้อมูลอยู่ในแคชจากการ prefetch แล้ว คอมโพเนนต์จะ render ทันทีโดยไม่ suspend หากการ prefetch ยังดำเนินอยู่หรือยังไม่ได้เริ่มต้น Suspense จะแสดง fallback จนกว่าข้อมูลจะพร้อม

การจัดการข้อผิดพลาดด้วย Suspense และ Error Boundaries

ในขณะที่ Suspense จัดการสถานะ 'loading' โดยการแสดง fallback แต่ไม่ได้จัดการสถานะ 'error' โดยตรง หาก promise ที่ถูก throw โดยคอมโพเนนต์ที่ suspend ถูก reject (เช่น การดึงข้อมูลล้มเหลว) ข้อผิดพลาดนี้จะถูกส่งต่อไปยัง component tree ด้านบน เพื่อจัดการข้อผิดพลาดเหล่านี้อย่างสวยงามและแสดง UI ที่เหมาะสม คุณต้องใช้ Error Boundaries

Error Boundary คือ React component ที่ใช้งาน lifecycle methods componentDidCatch หรือ static getDerivedStateFromError มันจะจับข้อผิดพลาด JavaScript ที่ใดก็ได้ใน child component tree ของมัน รวมถึงข้อผิดพลาดที่ถูก throw โดย promise ที่ Suspense ปกติจะจับได้หากยังอยู่ในสถานะ pending

            import React, { Suspense, useState } from 'react';
import { QueryClient, QueryClientProvider, useQuery } from '@tanstack/react-query';

// --- Error Boundary Component --- //
class MyErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
    this.state = { hasError: false, error: null };
  }

  static getDerivedStateFromError(error) {
    // Update state so the next render will show the fallback UI.
    return { hasError: true, error };
  }

  componentDidCatch(error, errorInfo) {
    // You can also log the error to an error reporting service
    console.error(\"Caught an error:\", error, errorInfo);
  }

  render() {
    if (this.state.hasError) {
      // You can render any custom fallback UI
      return (
        <div style={{\"border\": \"2px solid red\", \"padding\": \"20px\", \"margin\": \"20px 0\", \"background\": \"#ffe0e0\"}}>
          <h2>Something went wrong!</h2>
          <p>{this.state.error && this.state.error.message}</p>
          <p>Please try refreshing the page or contact support.</p>
          <button onClick={() => this.setState({ hasError: false, error: null })}>Try Again</button>
        </div>
      );
    }
    return this.props.children;
  }
}

// --- Data Fetching (with potential for error) --- //
const fetchItemById = async (id) => {
  console.log(`Attempting to fetch item ${id}...`);
  return new Promise((resolve, reject) => setTimeout(() => {
    if (id === 'error-item') {
      reject(new Error('Failed to load item: Network unreachable or item not found.'));
    } else if (id === 'slow-item') {
      resolve({ id: 'slow-item', name: 'Delivered Slowly', data: 'This item took a while but arrived!', status: 'success' });
    } else {
      resolve({ id, name: `Item ${id}`, data: `Data for item ${id}` });
    }
  }, id === 'slow-item' ? 3000 : 800));
};

const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      suspense: true,
      retry: false, // For demonstration, disable retry so error is immediate
    },
  },
});

function DisplayItem({ itemId }) {
  const { data: item } = useQuery({
    queryKey: ['item', itemId],
    queryFn: () => fetchItemById(itemId),
  });

  return (
    <div>
      <h3>Item Details:</h3>
      <p>ID: {item.id}</p>
      <p>Name: {item.name}</p>
      <p>Data: {item.data}</p>
    </div>
  );
}

function App() {
  const [fetchType, setFetchType] = useState('normal-item');

  return (
    <QueryClientProvider client={queryClient}>
      <h1>Suspense and Error Boundaries</h1>

      <div>
        <button onClick={() => setFetchType('normal-item')}>Fetch Normal Item</button>
        <button onClick={() => setFetchType('slow-item')}>Fetch Slow Item</button>
        <button onClick={() => setFetchType('error-item')}>Fetch Error Item</button>
      </div>

      <MyErrorBoundary>
        <Suspense fallback={<p>Loading item via Suspense...</p>}>
          <DisplayItem itemId={fetchType} />
        </Suspense>
      </MyErrorBoundary>
    </QueryClientProvider>
  );
}

            

              
                Copy
              
            
          

ด้วยการห่อ Suspense boundary (หรือคอมโพเนนต์ที่อาจ suspend) ด้วย Error Boundary คุณจะมั่นใจได้ว่าความล้มเหลวของเครือข่ายหรือข้อผิดพลาดของเซิร์ฟเวอร์ระหว่างการดึงข้อมูลจะถูกจับและจัดการอย่างเหมาะสม ป้องกันไม่ให้แอปพลิเคชันทั้งหมดล่ม ซึ่งมอบประสบการณ์ที่แข็งแกร่งและเป็นมิตรต่อผู้ใช้ ทำให้ผู้ใช้เข้าใจปัญหาและอาจลองใหม่อีกครั้งได้

การจัดการ State และ Data Invalidation ด้วย Suspense

สิ่งสำคัญที่ต้องชี้แจงคือ React Suspense จัดการสถานะการโหลดเริ่มต้นของทรัพยากร asynchronous เป็นหลัก มันไม่ได้จัดการแคชฝั่งไคลเอ็นต์, การ invalidation ข้อมูล หรือการจัดการ mutations (การสร้าง, อัปเดต, ลบ) และการอัปเดต UI ที่ตามมาโดยเนื้อแท้

นี่คือจุดที่ไลบรารีการดึงข้อมูลที่รองรับ Suspense (React Query, SWR, Apollo Client, Relay) กลายเป็นสิ่งที่ขาดไม่ได้ พวกมันเติมเต็ม Suspense โดยการให้:

• การแคชที่แข็งแกร่ง: พวกมันดูแลแคชในหน่วยความจำของข้อมูลที่ดึงมาอย่างซับซ้อน ให้บริการทันทีหากมีอยู่ และจัดการการ revalidation ในเบื้องหลัง
• การ Invalidation และ Refetching ข้อมูล: พวกมันมีกลไกในการทำเครื่องหมายข้อมูลที่แคชไว้ว่าเป็น 'stale' และดึงข้อมูลใหม่ (เช่น หลังจากการ mutation, การโต้ตอบของผู้ใช้ หรือเมื่อ window focus)
• Optimistic Updates: สำหรับ mutations พวกมันช่วยให้คุณสามารถอัปเดต UI ได้ทันที (แบบมองโลกในแง่ดี) ตามผลลัพธ์ที่คาดหวังของการเรียก API แล้วจึงย้อนกลับหากการเรียก API จริงล้มเหลว
• การซิงโครไนซ์ State แบบ Global: พวกมันทำให้แน่ใจว่าหากข้อมูลเปลี่ยนแปลงจากส่วนหนึ่งของแอปพลิเคชันของคุณ คอมโพเนนต์ทั้งหมดที่แสดงข้อมูลนั้นจะได้รับการอัปเดตโดยอัตโนมัติ
• สถานะการโหลดและข้อผิดพลาดสำหรับ Mutations: ในขณะที่ useQuery อาจ suspend, useMutation มักจะให้สถานะ isLoading และ isError สำหรับกระบวนการ mutation เอง เนื่องจากการ mutation มักเป็นการโต้ตอบและต้องการการตอบสนองทันที

หากไม่มีไลบรารีการดึงข้อมูลที่แข็งแกร่ง การใช้งานฟีเจอร์เหล่านี้บนตัวจัดการทรัพยากร Suspense ที่สร้างขึ้นเองจะเป็นงานที่ใหญ่มาก ซึ่งโดยพื้นฐานแล้วต้องการให้คุณสร้างเฟรมเวิร์กการดึงข้อมูลของคุณเอง

ข้อควรพิจารณาในทางปฏิบัติและแนวทางปฏิบัติที่ดีที่สุด

การนำ Suspense มาใช้สำหรับการดึงข้อมูลเป็นการตัดสินใจทางสถาปัตยกรรมที่สำคัญ นี่คือข้อควรพิจารณาบางประการสำหรับแอปพลิเคชันระดับโลก:

1. ไม่ใช่ข้อมูลทั้งหมดที่ต้องการ Suspense

Suspense เหมาะอย่างยิ่งสำหรับข้อมูลสำคัญที่ส่งผลกระทบโดยตรงต่อการ render เริ่มต้นของคอมโพเนนต์ สำหรับข้อมูลที่ไม่สำคัญ, การดึงข้อมูลเบื้องหลัง หรือข้อมูลที่สามารถโหลดแบบ lazy ได้โดยไม่มีผลกระทบทางสายตาที่ชัดเจน การใช้ useEffect แบบดั้งเดิมหรือ pre-rendering อาจยังคงเหมาะสม การใช้ Suspense มากเกินไปอาจนำไปสู่ประสบการณ์การโหลดที่ไม่ละเอียด เนื่องจาก Suspense boundary อันเดียวจะรอให้ลูกๆ *ทั้งหมด* ของมัน resolve

2. ความละเอียดของ Suspense Boundaries

วาง <Suspense> boundaries ของคุณอย่างรอบคอบ boundary ขนาดใหญ่เพียงอันเดียวที่ด้านบนสุดของแอปพลิเคชันอาจซ่อนทั้งหน้าไว้หลัง spinner ซึ่งอาจน่ารำคาญ boundary ที่เล็กกว่าและละเอียดกว่าจะช่วยให้ส่วนต่างๆ ของหน้าเว็บของคุณโหลดได้อย่างอิสระ ทำให้เกิดประสบการณ์ที่ก้าวหน้าและตอบสนองได้ดีขึ้น ตัวอย่างเช่น boundary รอบๆ คอมโพเนนต์โปรไฟล์ผู้ใช้ และอีกอันรอบๆ รายการผลิตภัณฑ์แนะนำ

            <div>
  <h1>Product Page</h1>
  <Suspense fallback={<p>Loading main product details...</p>}>
    <ProductDetails id=\"prod123\" />
  </Suspense>

  <hr />

  <h2>Related Products</h2>
  <Suspense fallback={<p>Loading related products...</p>}>
    <RelatedProducts category=\"electronics\" />
  </Suspense>
</div>

            

              
                Copy
              
            
          

แนวทางนี้หมายความว่าผู้ใช้สามารถเห็นรายละเอียดผลิตภัณฑ์หลักได้แม้ว่าผลิตภัณฑ์ที่เกี่ยวข้องจะยังโหลดอยู่

3. Server-Side Rendering (SSR) และ Streaming HTML

API สำหรับ streaming SSR ใหม่ของ React 18 (renderToPipeableStream) ทำงานร่วมกับ Suspense ได้อย่างสมบูรณ์ สิ่งนี้ช่วยให้เซิร์ฟเวอร์ของคุณส่ง HTML ทันทีที่พร้อมใช้งาน แม้ว่าบางส่วนของหน้า (เช่น คอมโพเนนต์ที่ต้องใช้ข้อมูล) จะยังโหลดอยู่ก็ตาม เซิร์ฟเวอร์สามารถสตรีม placeholder (จาก Suspense fallback) แล้วจึงสตรีมเนื้อหาจริงเมื่อข้อมูล resolve โดยไม่ต้อง re-render ทั้งหมดฝั่งไคลเอ็นต์ สิ่งนี้ช่วยปรับปรุงประสิทธิภาพการโหลดที่รับรู้ได้อย่างมากสำหรับผู้ใช้ทั่วโลกในสภาพเครือข่ายที่หลากหลาย

4. การนำมาใช้ทีละส่วน (Incremental Adoption)

คุณไม่จำเป็นต้องเขียนแอปพลิเคชันทั้งหมดของคุณใหม่เพื่อใช้ Suspense คุณสามารถนำมาใช้ทีละส่วนได้ โดยเริ่มจากฟีเจอร์ใหม่หรือคอมโพเนนต์ที่จะได้รับประโยชน์สูงสุดจากรูปแบบการโหลดแบบ declarative ของมัน

5. เครื่องมือและการดีบัก

ในขณะที่ Suspense ทำให้ตรรกะของคอมโพเนนต์ง่ายขึ้น การดีบักอาจแตกต่างออกไป React DevTools ให้ข้อมูลเชิงลึกเกี่ยวกับ Suspense boundaries และสถานะของมัน ทำความคุ้นเคยกับวิธีที่ไลบรารีการดึงข้อมูลที่คุณเลือกเปิดเผยสถานะภายในของมัน (เช่น React Query Devtools)

6. การหมดเวลาสำหรับ Suspense Fallbacks

สำหรับการโหลดที่ใช้เวลานานมาก คุณอาจต้องการกำหนดเวลาหมดเวลาให้กับ Suspense fallback ของคุณ หรือเปลี่ยนไปใช้ loading indicator ที่มีรายละเอียดมากขึ้นหลังจากผ่านไประยะหนึ่ง hook useDeferredValue และ useTransition ใน React 18 สามารถช่วยจัดการสถานะการโหลดที่ละเอียดอ่อนเหล่านี้ได้ ช่วยให้คุณสามารถแสดง UI เวอร์ชัน 'เก่า' ในขณะที่ข้อมูลใหม่กำลังถูกดึง หรือเลื่อนการอัปเดตที่ไม่เร่งด่วนออกไป

อนาคตของการดึงข้อมูลใน React: React Server Components และอื่นๆ

การเดินทางของการดึงข้อมูลใน React ไม่ได้หยุดอยู่แค่ Suspense ฝั่งไคลเอ็นต์ React Server Components (RSC) แสดงถึงวิวัฒนาการที่สำคัญ ซึ่งสัญญาว่าจะทำให้เส้นแบ่งระหว่างไคลเอ็นต์และเซิร์ฟเวอร์ไม่ชัดเจน และเพิ่มประสิทธิภาพการดึงข้อมูลให้ดียิ่งขึ้น

• React Server Components (RSC): คอมโพเนนต์เหล่านี้ render บนเซิร์ฟเวอร์, ดึงข้อมูลโดยตรง แล้วจึงส่งเฉพาะ HTML และ JavaScript ฝั่งไคลเอ็นต์ที่จำเป็นไปยังเบราว์เซอร์ สิ่งนี้ช่วยกำจัด waterfalls ฝั่งไคลเอ็นต์, ลดขนาด bundle และปรับปรุงประสิทธิภาพการโหลดเริ่มต้น RSC ทำงานร่วมกับ Suspense อย่างใกล้ชิด: server components สามารถ suspend ได้หากข้อมูลยังไม่พร้อม และเซิร์ฟเวอร์สามารถสตรีม Suspense fallback ไปยังไคลเอ็นต์ ซึ่งจะถูกแทนที่เมื่อข้อมูล resolve นี่คือ game-changer สำหรับแอปพลิเคชันที่มีความต้องการข้อมูลที่ซับซ้อน โดยมอบประสบการณ์ที่ราบรื่นและมีประสิทธิภาพสูง โดยเฉพาะอย่างยิ่งสำหรับผู้ใช้ในภูมิภาคทางภูมิศาสตร์ต่างๆ ที่มี latency แตกต่างกัน
• การดึงข้อมูลแบบครบวงจร (Unified Data Fetching): วิสัยทัศน์ระยะยาวสำหรับ React เกี่ยวข้องกับแนวทางการดึงข้อมูลแบบครบวงจร โดยที่เฟรมเวิร์กหลักหรือโซลูชันที่ผสานรวมอย่างใกล้ชิดจะให้การสนับสนุนระดับเฟิร์สคลาสสำหรับการโหลดข้อมูลทั้งบนเซิร์ฟเวอร์และไคลเอ็นต์ ซึ่งทั้งหมดนี้ประสานงานโดย Suspense
• วิวัฒนาการของไลบรารีอย่างต่อเนื่อง: ไลบรารีการดึงข้อมูลจะยังคงพัฒนาต่อไป โดยนำเสนอฟีเจอร์ที่ซับซ้อนยิ่งขึ้นสำหรับการแคช, การ invalidation และการอัปเดตแบบเรียลไทม์ โดยสร้างขึ้นจากความสามารถพื้นฐานของ Suspense

ในขณะที่ React ยังคงเติบโตต่อไป Suspense จะเป็นส่วนสำคัญของจิ๊กซอว์สำหรับการสร้างแอปพลิเคชันที่มีประสิทธิภาพสูง เป็นมิตรต่อผู้ใช้ และบำรุงรักษาง่าย มันผลักดันให้นักพัฒนามุ่งสู่แนวทางการจัดการการทำงานแบบ asynchronous ที่เป็น declarative และทนทานมากขึ้น โดยย้ายความซับซ้อนจากคอมโพเนนต์แต่ละตัวไปยัง data layer ที่มีการจัดการอย่างดี

สรุป

React Suspense ซึ่งในตอนแรกเป็นฟีเจอร์สำหรับการทำ code splitting ได้เบ่งบานเป็นเครื่องมือที่เปลี่ยนแปลงการดึงข้อมูล ด้วยการนำรูปแบบ Fetch-As-You-Render มาใช้และใช้ประโยชน์จากไลบรารีที่รองรับ Suspense นักพัฒนาสามารถปรับปรุงประสบการณ์ผู้ใช้ของแอปพลิเคชันได้อย่างมาก กำจัด loading waterfalls, ลดความซับซ้อนของตรรกะคอมโพเนนต์ และมอบสถานะการโหลดที่ราบรื่นและประสานงานกัน เมื่อรวมกับ Error Boundaries สำหรับการจัดการข้อผิดพลาดที่แข็งแกร่งและอนาคตที่สดใสของ React Server Components, Suspense ช่วยให้เราสามารถสร้างแอปพลิเคชันที่ไม่เพียงแต่มีประสิทธิภาพและทนทาน แต่ยังน่าใช้งานสำหรับผู้ใช้ทั่วโลกโดยเนื้อแท้ การเปลี่ยนไปใช้กระบวนทัศน์การดึงข้อมูลที่ขับเคลื่อนด้วย Suspense ต้องการการปรับแนวคิด แต่ผลประโยชน์ในด้านความชัดเจนของโค้ด, ประสิทธิภาพ และความพึงพอใจของผู้ใช้นั้นมีนัยสำคัญและคุ้มค่ากับการลงทุนอย่างแน่นอน